FunnelFlux tiene tres acciones principales relacionadas con la navegación que ocurren:
- Carga de enlace de entrada:
/fts/ - Carga de enlace de acción:
/action/x - Seguimiento de vista de página por JS: POST a
/js/funnel
Los enlaces de entrada son bastante estrictos y contienen todos los datos necesarios para dirigir a un destino (ya que los habrías generado en nuestra interfaz de usuario), y si funcionan, irán exactamente donde se especifica, ignorando cualquier otro historial contextual ya que un enlace de entrada es una entrada nueva e independiente a un embudo.
En los dos últimos casos, el borde de FunnelFlux Pro utiliza la información disponible para determinar en qué nodo/página se encuentra un usuario y, en el caso de las acciones, qué conexión seguir.
Estos pueden ser propensos a problemas si no se configuran correctamente, por lo que esta sección resumirá cómo el JavaScript y los enlaces de acción determinan la página actual y la página/nodo de origen, respectivamente.
Lógica de enlace de acción
Los enlaces de acción siempre ejecutarán la acción numerada que se extiende desde el nodo en el que creen que se encuentra el visitante.
Al probar un embudo y navegar por él, es útil considerar el diagrama del embudo y cómo cada acción resulta en que te muevas de un nodo al siguiente, manteniendo un registro de en qué nodo te encuentras (es decir, lo que el rastreador sabe que estás).
Considera una situación donde vas a una página > haces clic en un enlace de acción > se abre en una nueva pestaña. Vuelves a la pestaña original y haces clic en un enlace nuevamente. Ahora estás iniciando una acción desde un nodo anterior que viene antes de la posición de nodo conocida actual.
Considera un segundo escenario pero donde el enlace de acción no se abre en una nueva pestaña. Luego haces clic en el botón de retroceso de tu navegador, cargando la página anterior. Si no hay JS de seguimiento de vista en esta página, el rastreador no sabe que has navegado de vuelta a ella. Si haces clic en un enlace de acción ahora, una vez más estás iniciando una acción desde un nodo anterior.
En ambos casos, el rastreador necesita algún mecanismo para determinar estos clics repetidos, determinando el nodo de origen de un clic.
Manejo del referente
Al cargar un enlace de acción, nuestro borde verificará el referente.
Si este referente contiene un VID, el borde ahora es consciente de la sesión del visitante (sin necesidad de cookies).
Si este referente contiene la URL completa de la página, el rastreador ahora puede hacer coincidir esa URL con nodos/páginas conocidos en el embudo, así como páginas visitadas anteriormente, para determinar que el clic provino de una página que ya fue visitada (un evento necesario para que exista un clic).
Si el referente contiene un parámetro n=NODE_ID en la URL, el rastreador ahora puede determinar con precisión el nodo de origen, sin depender de la coincidencia de URL de página. Esto es más específico, ya que la misma página podría usarse varias veces en el mismo embudo (con diferentes IDs de nodo), o una página podría estar incrustada en un iFrame donde la URL principal y, por lo tanto, el referente no representa la página cargada.
Por eso nuestro JavaScript tiene dos funciones auxiliares:
Una que verifica la etiqueta <meta name="referrer"> en la página y, si está presente, actualiza su valor a no-referrer-when-downgrade, y si no está presente, la crea.
Una segunda función que reescribe la ubicación de la página actual para incluir el ID del visitante y el ID del nodo actual en la URL, haciendo que el valor completo del referente sea altamente informativo para el manejador de enlaces de acción.
Dado esto, uno debería evitar tener atributos rel="noreferrer" agregados a los enlaces. ¡Esto es algo sin sentido -- ocultar información de tu propio sistema de seguimiento!
Matiz con páginas alojadas en un dominio raíz
Puede surgir un matiz interesante cuando no se pasa el referente completo.
Considera un embudo que tiene una página de destino inicial A en https://domain.com (es decir, el dominio raíz/página de inicio), que se conecta a una segunda página B con URL https://domain.com/some-page/
En el navegador, el usuario cargará la página A y navegará con éxito a la página B.
Sin embargo, en la página B, si no se pasa el referente completo, el siguiente clic de acción puede pasar un referente truncado (solo el nombre de host). Nuestro borde entonces ve un clic aparentemente proveniente de "domain.com".
De manera única, ya que el usuario ha usado su dominio raíz como una página, este referente es la URL/ruta conocida del lander anterior, por lo que el rastreador determinará correctamente, con la información dada, que esto es en realidad un clic repetido desde la página A.
Esto conduce a un bucle de redirección de página A > clic > página B > clic > página B > clic página B
Inyección directa de parámetros de URL
Otra de nuestras funciones auxiliares de JS detectará elementos <a> en una página donde href contiene /action, luego inyectará:
...&vid=VISITOR_ID&rn=CURRENT_NODE_ID
Si esto ocurre, la información del referente no se usa, ya que los parámetros de URL especificados directamente tienen prioridad.
Se podría argumentar que las funciones de referente y reescritura de URL pueden ser útiles -- pero este no es el caso.
Hay muchas situaciones donde los usuarios pueden agregar código JS a una página, pero no usan elementos <a> simples para redirigir a la siguiente página. Pueden tener elementos <a> pero que enlazan directamente a otras páginas, donde no pueden inyectar parámetros en esas URLs. Las redirecciones a URLs de acción también podrían ser manejadas por JavaScript, donde el usuario tiene poco control o control dinámico.
En cualquier caso, el parámetro "rn" especifica explícitamente a nuestro borde que un clic proviene de un nodo específico para el visitante correspondiente. Es la forma más robusta de garantizar un seguimiento confiable.
En casos avanzados donde la redirección a enlaces de acción no implica elementos <a> simples, sino manipulación de JavaScript, recomendamos usar la función onDone() en nuestro JS de seguimiento de vistas.
Puedes usar esto para obtener el ID de nodo actual y el ID de visitante, luego inyectar estos en cualquier función que controle la redirección > agregar manualmente los parámetros de URL anteriores a la URL de acción, proporcionando el mismo beneficio.
Parámetros de acción predeterminados
Estos se pueden activar al usar el elemento de menú contextual "obtener enlace de acción" en el constructor de embudos.
Solo están disponibles aquí ya que deben ser específicos para un embudo y nodo.
Este interruptor es solo para la generación, no aplica ningún efecto específico al embudo/nodo en sí.
Estas URLs declaran un ID de embudo y nodo predeterminados, así:
https://USER_DOMAIN/FUNNEL_ID/ORIGINATING_NODE_ID/action/number
Es importante notar que estos valores NO son anulaciones, solo se usarán para una solicitud de enlace de acción donde no se conoce el valor VID, es decir, un visitante nuevo o desconocido.
Por lo tanto, funcionarán en una ventana de incógnito, mientras que los enlaces de acción genéricos/universales, sin contexto, no lo harían.
En el 99% de los casos, estos parámetros de respaldo no se usan -- pero hay algunos escenarios donde son útiles, si no críticos:
- Al hacer envíos de formularios que redirigen a través de algún tercero antes de volver a una URL de redirección que se establece en ese tercero. Aquí, debido a los saltos aleatorios que no controlas, si usaras un enlace de acción genérico, probablemente se cargaría y no tendría información útil del referente (solo información del sistema aleatorio de terceros). El borde solo podría usar cookies para determinar el VID (¡no es confiable!), por lo que los parámetros predeterminados serían importantes para al menos llevar al usuario al destino esperado, incluso si su sesión se pierde y se desconectan de su entrada original al embudo. Si el tercero pudiera ingerir y pasar parámetros de URL hacia adelante, ¡genial! Pero, en muchos casos esto no está disponible...
- Al enviar usuarios a alguna página donde necesitan hacer clic para llegar a un enlace de acción, pero por cualquier razón, no es posible controlar el código de la página para inyectar nuestro JS que ayudaría a pasar el referente/datos
- Cuando los usuarios pueden saltar de una página conocida y rastreada a otras páginas y luego volver a una página conocida -- por ejemplo, a través de algún flujo de seminario web, donde es probable que pierdas el seguimiento de la sesión pero aún quieres rastrear algunas acciones/clics finales y asegurarte de que los visitantes aún se redirijan a un destino previsto
En otras palabras, estos enlaces de acción son útiles en todas las situaciones irritantes donde no tienes control para hacer que el seguimiento sea robusto y puedes esperar cero confiabilidad de referente/cookies/paso de datos, pero aún quieres que las personas carguen un enlace que controlas en algún momento posterior.
Lógica de seguimiento de vista de página JavaScript
El evento de seguimiento de vista de página a través de nuestro JS solo tiene dos fuentes de datos: la URL actual (y su cadena de consulta) y los atributos incrustados.
Los parámetros de URL siempre tienen prioridad. De esta manera, una página puede incrustar JS con IDs predeterminados seleccionados, pero los enlaces de entrada generados en nuestra interfaz de usuario siempre se rastrearán como se espera al anular esos valores.
En el caso de enlaces directos, los parámetros de URL de la cadena de consulta anulan los valores predeterminados de JS.
En el caso de enlaces de redirección, la página resultante se carga sin esos parámetros pero con un valor vid=VISITOR_ID inyectado.
Este VID se pasa en la solicitud POST de JS y por lo tanto devuelve el ID de nodo ya conocido al que el usuario está navegando, que luego anula los valores predeterminados de JS.
Aquí hay algunos otros escenarios y el comportamiento resultante:
- Un enlace de redirección carga la página, que tiene JS pero sin valores predeterminados incrustados. Aquí el VID estará presente en la URL y se usará, y se usará la URL de la página para determinar la página actual. Es probable que coincida con el destino al que fue la redirección, lo que resulta en que no se genere una vista de página adicional (deduplicación)
- Una página se carga sin parámetros de URL y JS sin parámetros incrustados establecidos. El seguimiento de vista fallará, ya que siempre se debe pasar un ID de embudo -- solo funcionaría si hubiera un VID presente para determinar la sesión, que contendría un ID de embudo actual.
- Un enlace de redirección carga una página que tiene JS en ella, conteniendo parámetros incrustados que no coinciden con la sesión/embudo actual. En este caso, el VID será conocido y tendrá prioridad, por lo que el embudo no cambiará. La redirección ya ha generado una vista a la página esperada, y el evento de vista de JS rastreará automáticamente con coincidencia de URL. Si el JS especifica un ID de página que no coincide con la página que sirvió la redirección, puede causar una vista anómala separada si el ID de página declarado existe en el embudo actual (de lo contrario, daría un error)
- No hay parámetros de URL presentes. Se utilizan parámetros incrustados pero con un ID de página especificado que no existe en el embudo actual. La vista fallará en rastrear.
- No hay parámetros de URL presentes. Los parámetros incrustados usan un ID de nodo que no existe en el ID de embudo declarado. La vista fallará en rastrear.
- No hay parámetros de URL presentes. Hay un ID de página presente, pero la URL actual no coincide con ese ID de página. El borde honrará el ID de página, ignorando la coincidencia de URL. Esto permite que el iframe/incrustación funcione como se espera.